Different in their goal and capabilities, Graphing Calculator and IZIC are also quite different in their implementation.

The Graphing Calculator

     The Graphing Calculator is a fairy compact program composed of a formula editor, a rudimentary symbolic computation component, and a plotting engine. Each part is tied to the others by explicit function calls, data sharing, and a common user interface. The whole program is closed in that it cannot visualize data computed by an external system, nor have its own data visualized by external renderer. Another restriction is the absence of any programming or scripting language. No end user can define a new mathematical operator or alter the behavior of the interface.
     These restrictions in the Graphing Calculator are actually essential to simplify the implementation of honest plotting as well as several of its interactive capabilities. Everytime a user clicks on the zoom button (resp. moves an axis), the plotting engine request an on-the-fly computation of more points in order to maintain the picture accuracy (resp. fill the discovered area). In the same manner, when the user plays with the slider to study a family of surfaces, the action attached to the slider motion consists of recomputing the function from scratch with the new value of the parameter. In all these examples there is a clear interdependence between the parts of the program which compute the points display the graph, and manage the user's actions.
     The Graphing Calculator easily achieves such an interdependence by enforcing a strict correspondence between the equation displayed in the formula editor, the function to be plotted, and the graph displayed. Each part of the program shares actually the same data structures. Information such as which function should be recomputed or which range should be used now are either implicit or passed as function call parameters.

IZIC

     Compared with the Graphing Calculator, IZIC follows just an opposite philosophy: a package as open and extensible as possible. IZIC is a separate program whose ability is restricted to the visualization of curves and surfaces computed by external applications. It runs as a Unix server which interprets TCL scripts sent remotely from other programs and interacts with the user via its control panel.
     With the present implementation of IZIC, graphic objects to be visualized are defined using an ASCII representation: the ZIC format. Files in this format include a series of optional and mandatory fields: type of the objects, bounding box, colors, object encoding, etc. Typically, object encoding is a long collection of floats whose structure depends upon the type of the object.
     The role of an interface between a CA system and IZIC is therefore to generate representations of curves and surfaces in this format, and then, to communicate with IZIC by sending TCL scripts in order to remotely animate the surface, change the lighting parameters, etc. Typically, such an interface provides a collection of user-level commands (such as Plot2D, Plot3D, Sphere, Cone, Show, etc.) which extend or supplement existing graphing capabilities of the CA system.
     By totally decoupling the computation of mathematical objects and their visualization, any end user can select the CA system he prefers to construct the data, and then use IZIC (or any other equivalent software) to display and manipulate the graphics. Unfortunately, such a decoupling makes implementations of various interactive manipulations (like most of those available with the Graphing Calculator) conceptually and technically much more difficult.

Bridging the gap

     Most of the unique features of the Graphing Calculator rely on the program's ability to compute and display fast. Its ease-of-use via direct manipulation relies also on a two-way communication scheme in which both the computing and rendering parts of the program call each other's subroutines directly. The usage of direct function calls results in a simple and efficient implementation.
     But two-way communications are much harder to setup between separate programs, especially when they were not originally designed to allow such interaction. In fact, several issues remain to be addressed in order to improve interactivity and efficiency in the case of portable plotting packages (i. e. packages which can be used with any existing CA system).
     One important issue is the development and standardization of communication protocols allowing efficient exchange of symbolic and numeric data. On-going efforts such as MP [GKW94] or OpenMath try to address these issues. However, enabling such a communication scheme between a graphing package and several CA system could prove to be a challenging goal because of the following requirements: (1) an efficient exchange of numeric data to allow zooming or study or family or surfaces in real time; (2) a two-way asynchronous communication in which each program can freely request the other one to plot or compute additional points at any time. Next versions of IZIC should explore those issues by using MP or OpenMath when communicating with one ore more CA system.
     An alternative communication scheme may involve that a CA system generates C-routines (resp. p-code) instead of numeric data and leaves it up to the graphic engine to produces whatever data is needed by compiling and executing the C-routines (resp. by interpreting the p-code). This way, most computing would be done on the graphics side while less data would need to be transmitted per frame.